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COMPUTING A PPARATUS AND METHODS OF OPERATING COMPUTING AP PARATUS 

■ " ' (HP Ref. 3080058) 

Technical Field 

This invention relates to computing apparatus and particularly, but not exclusively, to 
5 computing apparatus and methods of operating computing apparatus in a secure 
environment using security tokens. 



Background Art 

Security tokens, for example smart cards or cryptographic co-processors, have 
10 recently been proposed for various security functions including accessing computer platforms 
(or 'host platfonns-) and electronic commerce. For instance, a smart card storing confidential 
infomiation accessible only to a related user can be used by the user to log on to a 
computer, to sign a document, or to provide credentials needed for electronic commerce. 

In some cases, it is expected that more than one security token for plural different 
15 applications may need to be used in a single communication session, which starts as the 
user logs on to a host platform and finishes as the user logs off. 

One possible model works as follows. A user has a number of tokens and. in each 
session, they use one of these tokens (for example, a logon token) for authentication to a 
host platform in the logon process only. During the same session, the user separately uses 
20 other tokens (for example, auxiliary tokens) for other security functions, such as electronic 
payment or cryptography. 

Disclosure of the Invention 

In aniving at the present invention, the present inventors have appreciated the 

25 following three potential problems with this model: 

Problem A - there is an inherent danger of a user walking away after logging on to the 
host platform, thus allowing an impostor to use the platfonn. 

Problem B - a fake host platfonn may be able to steal sensitive infomnation from the 

30 user. 

Problem C - there are some auxiliary tokens whose owner's identities are not 

traceable to the owner of the logon token. In other words, ari .rnposlo.. wl.u does not own 

the logon token, may be able to use his own auxiliary tokens to impersonate the logon 
token's owner. 

35 In addressing one or more of the above problems, the present inventors propose a 

new arrangement to reduce, security risk and to establish a more trusted relationship 
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between a host platform and one or more security tokens. Typically, ttie an^angement 
implements a security control policy that is more refined than the policy in the prior art model, 
including periodic or repeated authentication. Preferred embodiments of the inv^ion 
implement mutual - authentication and - privilege - restriction. In particular. P^^^v 
5 embodiments utilise a novel method of binding the identity of a logon, or primary, s^Wrty 
token with one or more auxiliary tokens. Of utmost inlportance is that the invention meets 
the important criteria of being easy to use at relatively cheap to implement compared with 
prior art solutions. 

In accordance with a first aspect, the present invention provides computing apparatus 
10 comprising: 

memory means storing the instructions of a secure process and an 
authentication process; 

processing means arranged to control the operation of the computing 
apparatus including by executing the secure process and the authentication process as 
15 required; 

user interface means arranged to receive user input and return to the user 
information generated by the processing means in response to the user input; and 

interface means for receiving a removable primary token and communicating 
with the token, the token comprising a body supporting: 
20 a token interface for communicating with the interface means; 

a token processor; and 

token memory storing token data including information for identifying the 

token, 

wherein the processing means is arranged to receive the identity information 
25 from the primary token, authenticate the token using the authentication process and, if the^ 
token is successfully authenticated, permit a user to interact with the secure process via th^^ 
user interface means, 

and wherein the processing means is arranged to repeatedly authenticate the primary 
token and cause the computing platfonn to suspend interaction between the secure process 
30 and the user if authentication is not possible as a result of the removal of the primary token. 

In accordance with a second aspect, the present invention provides a method of 

controlling computing apparatus to authenticate a user, cuniprising the steps: 

the computing apparatus receiving a primary token of the user, the primary token 
containing information suitable for authenticating the primary token; 
35 if the token is authentic, permitting the user to interact with one or more secure 

applications that may be executed by the computing platform; 
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at intervals, re-authenticating the primary token; and 

if it is not possible to re-authenticate the primary token, suspending the interaction 
between the cxsmputing apparatus and the user. 

Other aspects of the -invention will -become apparent from the accompanying 

5 description, claims and drawings. 

Brief Description of the Drawings - to be updated 

Preferred embodiments of the present invention will now be described, by way of 
example only, with reference to the accompanying drawings, of which: 



.10 



Figure 1 is a diagram which illustrates a system capable of implementing 
embodiments of the present invention; 

Figure 2 is a diagram which illustrates a motherboard including a trusted device 
arranged to communicate with a number of smart cards via a single smart card readen 
15 Figure 3. is a diagram thai illustrates the trusted device in more detail; 

Figure 4 is a diagram that illustrates the operational parts of a logon smart card 

according to the present invention; 

Figure 5 is a flow diagram which illustrates the process of mutually authenticating a 

logon smart card and a host platfonn; 
20 Figure 6 is a flow diagram which illustrates one general example of introducing an 

auxiliary smart card to a host platfomn using by a logon smart card; 

Figure 7 is a flow diagram which illustrates one example of the operation between an 
introduced cash card and the host platform; 

Figure 8 is a flow diagram which illustrates one example of a single session 

25 temporary delegation mode; and 

Figure 9 is a flow diagram which illustrates one example of a multiple session 

temporary delegation mode. 

Best Mode For Carrying Out the Invention. & In dustrial Aoplicabltlty 
30 While the ideas of the invention are general, for ease of discussion, we will focus on 

preferred embodiments, wherein smart cards are the security tokens, which interact with a 

trusted computing platfomn. or s.mply ' pla tf omr. I .. pa.UuuU.. o uoor hoc one I ngnn smnrt 

card and a number of auxiliary smart cards, and needs to interact with the platform, wh.ch 
has only a single smart card reader. It is assumed In the present embodiment that there .s 
35 no way for more than one smart card to be read by the smart card reader at the same t.me. 
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In order to address Problem A. as highlighted in the "Description of Prior Art", the 
present embodiments implement a coherent security control policy using a logon smart card 
operating with the platform. Specifically, to limit the potential for an impostor getting ac 
to the trusted platform without the legitimate user's knowledgorthe logon smart card n| 
5 be present throughout the session, rather than just to initiate the session. By analogic le 
logon smart card is used more like a car key than a door key. 

In effect, a user is held responsible for their actions. Since the smart card has to be 
present during the execution of a command, this effectively and unambiguously holds the 
owner of the smart card responsible for the action. As will be described below, the 
10 authentication is done automatically by the platform and does not generally require actions 
from the user. This amounts to a saving of time for the user and is, thus, a very attractive 
feature. | 

A major strength of the proposed scheme lies in its intuitive appeal. People are 
familiar with the importance of pnDtecting their keys and accept full responsibility for 
15 respective misuse of the keys. The present scheme, which greatly enhances security, is 
simple to implement. As an added security feature, it is preferable that the logon smart card 
is also password protected, requiring a user to enter a password when the card is first 
inserted into the smart card reader. Password techniques are well-known and will not be 
described herein, so as not to obscure the Invention. 
20 Generally, to check the presence of the logon smart card, the platform needs 

repeatedly to authenticate the logon card. The actual frequency of the authentication can be 
configured by either a system administrator or the user. In practice, one would set the 
frequency high enough that the user, or an unauthorised user, would be unable to subvert 
the platfomi and cany out an unauthorised transaction between authentications. For 
25 example, authentication may occur every few seconds. m 
A further security feature that can be implemented in the security policy is a time-limit 
for each authenticated session using an auxiliary smart card. The user interface may also be 
locked unless a new round of authentication is performed within the pre-set time-limit. 
Further, preferably, time-stamping, or the use of nonces, is used to prevent ^replay attacks' 
30 during authentication. 

To address the fake host platform problem. Problem B above, the prefen-ed 

embodiments use the concept of a trusted device built Into thy plalfuriii. which allowo a uoor 

to verify" the integrity of the platform. The concept of such a tnjsted device is the subject of 
the applicant's co-pending European patent application entitled "Trusted Computing 
35 Platform" filed on 15 February 1999. the entire contents of which are hereby incorporated 
herein by reference. 
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TO address Problem C. as highlighted in the -Description of Prior Art", where an 
auxiliary smart card may not be traceable to the owner of the logon smart card, the present 
embodiments introduce the concept of a user profile that binds a user to a number of 
_ auxiliary smart cards. This makes the implementation of a coherent, comprehensive and 
' flexible security control policy extremely simple, inexpensive and transparent to the user. 

Generally, in the prefen^d embodiments, it is always assumed that logging on .s 
done by a logon smart card, and at some point of the session, the user (or the application 
running under the session) needs to use one or more auxiliary smart cards, so that removal 
of the logon card becomes necessary. To maintain the security policy of repeated 
10 authentication, there needs to be a security chain for the platfonn between tn^sting the logon 
smart card and tmsting other auxiliary smart cards. This chain is built by letting the logon 
smart card -introduce' the auxiliary cards to the platform, for example by using 'user profiles . 

For the sake of simplicity of description, only two types of auxiliary smart cards are 

considered in any detail herein: 
15 "Cash cards", which are smart cards having cash values (or credits) that are 

transferable; and 

-Crypto cards", which are smart cards whose privileges (such as encryption or 
signature supported by a private key) are not transferable. 

A trusted platform 10 incorporating a smart card reader 12 is illustrated in the diagram 
20 in Figure 1. The platfomi 10 includes the standard features of a keyboard 14. mouse 16 and 
visual display unit (VDU) 18. which provide the physical "user interface" of the platfomv 
Along Side the smart card reader 12. there are illustrated a logon smart card 19 and plural 

auxiliary smart cards 20. . ^ -, ■ *t, 

conveniently, the present invention uses the platfom, that is described in detail .n the 
25 present applicant's co-pending patent application referred to above. While this platform -s 
ideal for the purposes of the present embodiment, and allows a user to verify the integnty of 
the platfom.. use of the platfom. is by no means essential to the present invention, in 
particular, the present invention does not necessarily require a user to verify the integnty of 
the platform, which might be acceptable, for example, if the platfomn is a private platform in a 
30 users own home. The main advantage of using a platfomn having a tmsted device is realised 
in an environment where many users potentially have access to the platfom.. thereby 

providing reasonable oppo r Lunily fu i II. e platform to bo cub>rprtPrt in ^nrr^f>, way. The main 

features of a platfomn including a tmsted device will now be reproduced herein purely for the 
reader's convenience. 

35 AS illustrated in Figure 2, the motherboard 20 of the trusted computing platform 10 

(as described in the applicant's co-pending application) includes (among other standard 
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components) a main processor 21, main memory 22, a trusted device 24. a data bus 26 and 
respective control lines 27 and address lines 28, BIOS memory 29 containing the BIOS 
program for the platform 1 0 and an Input/Output (lO) device 23. which controls intei^ion 
between the components of the motherboard and the smart card reader 12, the keybc^^B|, 
5 the mouse 16 and the VDU IB. The main memory 22 is typically random access n^^fy 
(RAM), (n operation, the platform 10 loads the operating system, for example Windows 
NT™, into RAM from hard disk (not shown). Additionally, in operation, the platform 10 loads 
the processes or applications that may be executed by the platfomn 10 into RAM from hard 
disk (not shown), in the present case, the key applications are an authentication application 
10 and a secure application, the operations of which will be described below. 

Typically, for a conventional IBM^mpatible platform (i.e. a "PC"), the BIOS program 
is located in a special reserved memory area, the upper 64K of the first megabyte do the 
system memory (addresses F000h to FFFFh). and the main processor is an-anged to look 
at this memory location first, in accordance with an industry wide BIOS standard. 
15 A significant difference between the present tojsted platform 10 and a conventional 

platform is that, after reset, the main processor 21 is initially controlled by the trusted device 
24, which then hands control over to the platform-specific BIOS program, which in tum 
initialises all input/output devices as normal. After the BIOS program has executed, control 
is handed over as normal by the BIOS program to the operating system. 
20 The trusted device 24 comprises a number of blocks, as illustrated in Figure 3. After 

system reset, the trusted device 24 performs a secure boot process to ensure that the 
operating system of the platform 10 (including the system clock and the display on the 
monitor) is running property and In a secure manner. During the secure boot process, the 
trusted device 24 acquires an integrity metric of the computing platform 10. The trusted 
25 device 24 can also perform secure data transfer and. for example, authentication between it 
and a smart card via encryption/decryption and signature/verification. The trusted device 24^ 
can also securely enforce various security control policies to be discussed below including 
frequent authentication and the locking of user interface. 

Specifically, the trusted device 24 comprises: a controller 30 programmed to control 
30 the overall operation of the tnJSted device 24, and interact with the other functions on the 
trusted device 24 and with the other devices on the motherboard 10; a measurement function 

31 for acquinng the integrity r r^eliic f i um 1 1 lu pldtform 10: o cryptographic function 3? for 

signing, encrypting or decrypting specified data; an authentication function 33 for 
authenticating a logon smart card 19; and interface circuitry 34 having appropriate ports (36. 
35 37 & 38) for connecting the trusted device 24 respectively to the data bus 26. control lines 27 
and address lines 28 of the mothert>oard 10. Each of the blocks in the tmsted device 24 has 
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access (typically via the controller 20) to appropriate volatile memory areas 37 and/or non- 
volatile memory areas 38 of the trusted device 24. Additionally, the trusted device 24 is 
designed, in a known manner, to be tamper resistant. 

For reasons of performance, the trusted device 24 may be implemented as an 
I application specific integrated circuit (ASIC). However, for flexibility, the trusted device 24 is 
preferably an appropriately programmed micro-controller. Both ASICs and micn>control»ers 
are well known in the art of microelectronics and will not be considered herein in any further 

detail. ^. 

one item of data stored in the non-volatile memory of the trusted device 24 .s a 

10 certiiicate 350. The certificate 350 contains at least a public key 351 of the trusted device 24 
and an authenticated value 352 of the platfomi integrity metric measured by a trusted party 
(TP) The certificate 350 is signed by the TP using the TP's private key prior to .t be.ng 
stored in the tested device 24. In later communications sessions, a user of the platfomn 10 
can verify the integrity of the platform 10 by comparing an acquired integrity metric with the 
15 authentic integrity metric 352. If there is a match, the user can be confident that the platfom. 
10 has not been subverted. Knowledge of the TP's generally-available public key enables 
simple verification of the certificate 350. The non-volatile memory 35 also contains an 
identity (ID) label 353. The ID label 353 is a conventional ID label, for example a senal 
number, that is unique within some context. The ID label 353 is generally used for indexing 
20 and labelling of data relevant to the trusted device 24. but is insufficient in itself to prove the 
identity of the platform 10 under tnjsted condltlons. 

The trusted device 24 Is equipped with at least one method of reliably measunng or 
acquiring the integrity metric of the computing platform 10 with which it is associated. In the 
present embodiment, the integrity metric is acquired by the measurement function 31 by 
25 generating a digest of the BIOS instructions in the BIOS memory. Such an acquired integnty 
metric, if verified as described above, gives a potential user of the platfom. 10 a high level or 
confidence that the platfomi 10 has not been subverted at a hardware, or BIOS program 
level. Other known processes, for example virus checkers, will typically be in place to check 
that the operating system and application program code has not been subverted. 
30 The measurement function 31 has access to: non-voiatlle memory 35 for stonng a 

hash program 354 and a private key 355 of the trusted device 24: and volatile memory 42 for 

storing the public keys and c^^^uUaled ID labclo 360a . 360n of nnP or more authentic logon 

smart card 19s that can be used to gain access to the platform 10. and an acquired integnty 

metric in the form of a digest 361 . 
35 A processing part 40 of a logon smart card 19 is illustrated in Figure 4. As shown, the 

logon smart card 19 40 has the standard features of a processor 41. memory 42 and 
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interface contacts 43. The processor 41 is programmed for simple chailenge/respoase 
operations involving authentication of the logon smart card 19 and verification of the platform 
10, as will be described below. The memory 42 contains its private key 420. its pubU^ey 
428, a user profile 421, the public key 422 of the TP and an identity 427. The use^^^ 
5 421 lists the allowable auxiliary smart cards 20 AC1-ACn usable by the user. al^Ve 
individual security policy 424 for the user. For each auxiliary smart card 20, the user profile 
includes respective identification information 423. the trust structure 425 between the smart 
cards (if one exists) and. optionally, the type or make 426 of the smart card. 

In the user profile 421, each auxiliary smart card 20 entry ACI-ACn includes 
10 associated identification information 423. which varies in dependence upon the type of card. 
For example, identification infonmation for a cash card typically includes a simple serial 
number, whereas, for a crypto card, the identification information typically comprises the 
public key (or certificate) of the crypto card (the private key being stored secretly on the 
crypto card itself). 

15 The 'security policy* 424 dictates the permissions that the user has on the platform 10 

while using an auxiliary smart card 20. For example, the user interface may be locked or 
unlocked while an auxiliary smart card 20 is in use, depending on the function of the auxiliary 
smart card 20. Additionally, or alternatively, certain files or executable programs on the 
platform 10 may be made accessible or not, depending on how trusted a particular auxiliary 

20 smart card 20 is. Further, the security policy 424 may specify a particular mode of operation 
for the auxiliary smart card 20. such as 'credit receipt' or 'temporary delegation*, as will be 
described below. 

A 'trust structure' 425 defines whether an auxiliary smart card 20 can itself 'introduce' 
further auxiliary smart cards 20 into the system without first re-using the logon smart card 19. 
25 In the embodiments described in detail herein, the only defined trust structure is between the 
logon smart card 19 and the auxiliary smart cards 20 that can be introduced to the platfo 
10 by the logon smart card 19. Introduction may be 'single session' or ^multi-session', as will 
be described below. However, there is no reason why certain auxiliary smart cards 20 could 
not in practice introduce further auxiliary smart cards 20. This would require an auxiliary 
30 smart card 20 to have an equivalent of a user profile listing the or each auxiliary snnart card 
that it is able to introduce. 

A preferred process tor authentication belwt^en a l ogon amort cord 10 and a platfonn 

10 will now be described with reference to the flow diagram in Figure 5. As will be described, 
the process conveniently implements a challenge/response routine. Tliere exist many 
35 available challenge/response mechanisms. The implementation of an authentication 
protocol used in the present embodiment is mutual (or 3-step) authentication, as described in 
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ISO/IEC 9798-3 [1]. Of course, there is no reason why other authentication procedures 
cannot be used, for example 2-step or 4-step. as also described in [1]. 

Initially, the user inserts their logon smart card 19 into the smart card reader 12 of the 
platform 10 in step 500. Beforehand, the platform 10 will typically be operating under the 
control of its standard operating system and executing the authentication process, which 
waits for a user to insert their logon smart card 19. Apart from the smart card reader 12 
being active in this way, the platform 10 is typically rendered inaccessible to users by 
'locking* the user interface (i.e. the screen, keyboard and mouse). 

When the logon smart card 19 is inserted into the smart card reader 12. the trusted 
10 device 24 is triggered to attempt mutual authentication in step by generating and transmitting 
a nonce A to the logon smart card 19 in step 505. A nonce, such as a random number, is 
used to protect the originator from deception caused by replay of old but genuine responses 
(called a "replay attack") by untrustworthy third parties. 

In response, in step 510. the logon smart card 19 generates and returns a response 
15 comprising the concatenation of: the plain text of the nonce A, a new nonce B generated by 
the logon smart card 19, the ID 353 of the trusted device 24 and some redundancy: the 
signature of the plain text, generated by signing the plain text with the private key of the 
logon smart card 19: and a certificate containing the ID and the public key of the logon smart 
card 19. 

20 The tmsted device 24 authenticates the response by using the public key in the 

certificate to verify the signature of the plain text in step 515. If the response is not authentic, 
the process ends in step 520. If the response is authentic, in step 525 the tmsted device 24 
generates and sends a further response Including the concatenation of: the plain text of the 
nonce A, the nonce B. the ID 427 of the logon smart card 19 and the acquired integrity 

25 metric; the signature of the plain text, generated by signing the plain text using the private 
key of the trusted device 24; and the certificate comprising the public key of the trusted 
device 24 and the authentic integrity metric, both signed by the private key of the TP. 

The logon smart care! 19 authenticates this response by using the public key of the 
TP and comparing the acquired integrity metric with the authentic integrity metric, where a 

30 MidlU -i indicates 3UOCOoofu l vorification. in step 530 I f the further response is not authentic. 

the process ends in step 535. 

If the procedure is successful. t)oth the tmsted device 24 has authenticated the logon 
smart card 19 and the logon smart card 19 has verified the integrity of the trusted platform 10 
and. in step 540, the authentication process executes the secure process for the user. Then. 
35 the authentication process sets an interval timer in step 545. Thereafter, using appropriate 
operating system internjpt routines, the authentication process services the interval timer 
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periodically to detect when the timer meets or exceeds a pre-determined timeout period in 
step 550. 

Clearly, the authentication process and the interval timer run in parallel wj|ta|he 

secure process. ^^^^ 
5 When the timeout period is met or exceeded, the authentication process triggers the 

trusted device 24 to re-authenticate the logon smart card 19, by transmitting a challenge for 
the logon smart to identify itself in step 560. The logon smart card 19 returns a certificate 
including its ID 427 and its public key 428 step 565. In step 570. if there is no response (for 
example, as a result of the logon smart card 19 having been removed) or the certificate is no 
10 longer valid for some reason (for example, the logon smart card has been replaced with a 
different smart card), the session is tenninated by the tmsted device 24 in step 575.^ 
Otherwise, in step 570. the process from step 545 repeats by resetting the interval timer. 

A preferred, general process for introducing an auxiliary smart card 20 into a platform 
10 will now be described with reference to the flow diagram in Figure 6. 
15 When the secure process running on the platfomn 10 reaches a point where the logon 

smart card 19 needs to be replaced by an auxiliary smart card 20, for example at the time a 
cash card is needed to credit the platform 10 with funds for a remote transaction, in step 605 
the secure process retrieves the user profile from the trusted device 24 and stores it in its 
volatile memory 35. The trusted device 24 then extracts the details of the auxiliary smart 
20 cards (AC) 20 from the user profile and returns the details to the secure process in step 610. 
In step 615, the secure process displays an option list of auxiliary smart cards 20 and asks 
the user to select one. The secure process receives the users selection in step 620 and 
displays a message asking the user to replace the logon smart card 19 with the (or one of 
the) selected auxiliary smart card(s) 20 in step 625. As soon as the user ejects the logoq^ 
25 smart card 19. the trusted device locks the user interface in step 630 and. in step 635, the 
secure process initialises the authentication process interval timer with a new timeout period, 
which determines the allowable duration of the auxiliary smart card session. 

[In parallel with the operation of the secure process, which has been described with 
reference to Figure 5). if the timeout period expires before the logon smart card 19 has been 

30 re ins t at ed , th e auth e ntication procoGS Gucponds the sess i on (i p thR secure process) and 

provides the user with an appropriate message. The authentication process has the. 
authority to suspend the secure process, since it executed the secure process in the first 
instance. Clearly, the new timeout period needs to be sufficient for the required purposes, 
and may be configurable by a system administrator for this reason.] 
35 When the user inserts the selected auxiliary smart card 20, the tmsted device 24 is 

triggered to send the auxiliary smart card 20 a challenge to identify itself in step 640. The 
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auxiliary smart card 20 responds by returning its identity information to the tmsted device 24 
in step 645. The trusted device 24 then verifies the identity information by comparing it with 
the stored user profile information in step 650. 

Jf the trusted device 24 is unable to verify the auxiliary smart card 20 for any reason. 
5 in step 655 the session ends and the secure process displays an appropriate message for 
the user. Othenwise. in steps 660 and 665. the secure process interacts with the auxiliary 

smart card 20 as required. 

When the interaction is complete, in step 670. the secure process displays a prompt 

to the user to replace the auxiliary smart card 20 with the logon smart card 19. When the 
10 user ejects the auxiliary smart card 20 form the smart card reader 12 and inserts the logon 

smart card 19. the tmsted device 24 is triggered to authenticate the logon smart card 19. by 

executing from step 560 in Figure 5. as described above, resulting in the session ending in 

step 575 or continuing in step 545. 

Additionally, or alternatively, in some embodiments it may be required that the user 
15 profile, is encrypted and signed to protect privacy and integrity. If so, a secure data transfer 

protocol may be needed between the trusted device 24 and the logon smart card 19. There 

exist many available mechanisms for transfemng secure credentials between two entities. A 

possible implementation, which may be used in the present embodiment, is secure key 

transport mechanisms from ISO/IEC DIS 11770-3 [2]. 
20 Cleariy. the operation of the process that has just been described for introducing an 

auxiliary smart card 20 may vary in dependence upon the type of the auxiliary smart card 20; 

for example, whether it is a cash card or a crypto card. Variations in process for different 

types of auxiliary smart card 20 will now be described. 

25 CREDIT RECEIPT MODE 

A credit receipt mode allows a user to remove the logon smart card 19 for a very brief 
period Of time (say 2 minutes, which is configurable by a system administrator or a user) from 
the smart card reader 12 to allow credits (or cash values) from a cash card to be transferred 
to the trusted device 24 of the platform 10 without undue security risk. 

-3D i-igure 7 illuijt i amb the process for cnooting cr e d i t receipt mnriR The steps that 

con-espond to those illustrated in Figure 6 will not be spedfically described again. 

It is assumed that a user profile that lists auxiliary smart cards 20 including cash 
cards is stored in the logon smart card 19. As before, when a user invokes an application 
that requires cash values, the secure process displays a request for the user to choose a 
35 cash card ivom those listed in the user profile. 
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The first difference between the credit receipt mode process and the process in 
Figure 6 is that in step 721 the secure process displays a further request for the user to enter 
the amount of the credit transfer. The secure process receives the entered amount ijj|tep 
722 and forwards a respective value to the trusted device 24 in step 723. The tmste^^^Be 
5 24 transfers the credits from the cash card to the trusted device 24 in steps 760 and /65, 
after the cash card has been inserted and authenticated. 

As an altemative or additional feature, depending on the security policy, unauthorised 
cash cards may also be used; for example, there may be an option "Others" in the list of 
authorised cash cards. Cleariy. the risks associated with receiving credits from any auxiliary 

10 smart card 20 are relatively low. 

Typically, only a relatively short time is required to enact the whole process of 
transferring the credits. The length of the timeout period is determined by the security policy 
in the user profile. If the timeout is exceeded, the transfer process is aborted and the user 
interface is temporarily locked. On the other hand, if the user reinserts the logon smart card 

15 19 within the specified time-limit, a new round of authentication is performed between the 
smart card and the platform 10. Upon successful verification, the user interface will be 
unlocked and the original session, i.e. before the credit transfer mode, resumes, but with the 
cash value now stored In the tnjsted device 24. The cash value may be used for. for 
example, electronic commerce. 

20 Since the user interface is essentially locked during the credit transfer mode, and is 

re-activated only after the re-insertion of the logon smart card 19. the host platfonn 10 does 
not suffer any serious security risk in the credit receipt mode. Further, since the user has to 
authenticate which cash card to use, using the logon smart card 19. abuse of cash cards by 
illegal users is also minimised. ^ 

25 

TEMPORARY DELEGATION MODES 

It will be appreciated that for a crypto card to function (say for encryption, decryption, 
signature and verification), it potentially needs to be inserted in the place of a logon cand for a 
substantial amount of time, unlike for cash cards. To address the need for potentially greater 

30 periods of t i me to us e a crypto card, th e pr e s e nt embod i ment include . s what i s referred to as — 
a temporary delegation mode, which allows a user to use crypto cards in place of the logon 
card for an undefined time, subject to possible respective security policy limitations. 
Temporary delegation modes will now be described with reference to the flow diagram in 
Figure 8. The steps that correspond to those illustrated in Figure 6 will not be specifically 

35 described again. 
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To invoke a temporary delegation mode, a user (or the secure process) selects a 
temporary delegation mode in step 800 while the logon smart card 19 is being used. In 
response, the host platform 10 takes the steps to receive and authenticate the auxiliary smart 
card 20, which in this example is a crypto card. 

When provided with a list of allowable crypto cards, the user specifies the authorised 
crypto card. Depending on the security policy, unregistered crypto cards may or may not be 
used. Again, if the user profile is encrypted, a secure data transfer protocol (again, see [2]) 
may be employed. 

After the logon smart card 19 is removed, the user interface is locked and a the 
1 0 secure process displays a message requesting a new smart card. 

Upon insertion and authentication of the specified crypto card, the secure process 
activates user privileges in step 833 consistent with the security policy of the crypto card. 
For example, the user may need to use the user interface for entry of certain infomialjon 
related to the crypto card operation, but should not be able to execute any other process or 
1 5 perform any other operation. 

When the crypto card is removed from the smart card reader 12. the user interface is 
locked again, until the logon smart card 19 is inserted and authenticated. 

The example of the temporary delegation mode described above allows a single 
auxiliary smart card 20 to be used in a 'single session" in place of the logon smart card 19 for 
20 an undefined period of time. 

An alternative, or additional, temporary delegation mode pennits multiple auxiliary 
smart carrls 20 to be used In turn, in place of the logon smart card 19. without the need to re- 
insert the logon smart card 19. An example of such a "multi-session- temporary delegation 
mode will now be described with reference to Figure 9. As before, the steps that correspond 
25 to those illustrated in Figure 6 will not be specifically described again. 

m a multi-session, multiple auxiliary smart cards 20 can be freely used in place of the 
logon smart card 19. thus allowing maximal convenience of use. 

To invoke a multi-session temporary delegation mode, a user (or the secure process) 
selects a multi-session temporary delegation mode in step 900 while the logon smart card 19 

30 ia be i n g us ed . 

A significant difference between a multi-session temporary delegation mode and the 
single session temporary delegation mode is that, when provided with the list of available 
authorised auxiliary smart cards 20 in step 915. the user can select multiple authorised 
auxiliary smart cards 20 in step 920. The selected auxiliary smart cards 20 may be of 

35 different kinds depending on the user's requirements. 
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The host platform 10 takes the steps to receive and authenticate any one of the 
selected auxiliary smart cards 20. 

As soon as the logon smart card 19 is ejected the user Interface is locked, the j^|tfe 
process activates user privileges consistent with the operation of that auxiliary smart ^^^H) 
5 in step 933. When the auxiliary smart card 20 is eventually ejected, the process loops to 
step 925. a message is generated to replace the card and the user interface is locked again 
in step 930. When the next auxiliary smart card 20 is inserted, the secure process activates 
user privileges consistent with the operation of that auxiliary smart card 20 in step 933 again. 
This procedure may be repeated for any of the selected auxiliary smart cards 20 until 

10 the session ends or the logon smart card is re-inserted in step 975. In other words, the user 

can use any combination of the selected auxiliary smart cards 20 without the need of the ^ 
insertion of the logon smart card 19 during the whole multi-session. Cleariy, such a ^ 
permissive muiti-session is very convenient for the user, although the benefits need to be 
weighed against the risks of such freedom. 

15 Note that a security control policy described in the user profile may give constraints 

on the number, types and makes of smart cards allowed in a multi-session as well as any 
time-limits. Typically, different auxiliary smart cards 20 give the user different sets of 
privileges. For instance, some sensitive files may be locked whenever the auxiliary smart 
card 20 currently being used is regarded to be not trustworthy enough. Indeed, any truly 

20 sensitive application may require the insertion of the logon smart card 19 again for 
authentication. 

Since it is not easy to estimate how long a temporary delegation mode will last, in 
theory, it might be acceptable to have no timeout period as such, as in the examples above. 
However, there are risks associated with such a policy, for example a user may leave the ^ 

25 platform 10 during a temporary delegation mode session. Therefore, it is preferable to have 
an overall timeout period, fixed for the temporary delegation mode session, which overrides 
both the normal re-authentication timeout period of the authentication process and the 
individual timeout periods associated each auxiliary smart card 20. Additionally, it might also 
be possible to have individual timeout periods for certain auxiliary smart cards 20. As usual, 

30 the specification of the timeout period(s) will hp riRtprmineri by the security policies for the 

auxiliary smart cards 20. In practice, the timeout period for a temporary delegation mode is 
implemented by the secure process ovem'ding the authentication process. Exemplary fixed 
session timeout periods for temporary delegation modes are 30 minutes, 1 hour or 2 hours. 
The period(s) can be set or modified by the user or a system administrator, and may depend 

35 on the trustworthiness of the platform 10. 
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Re-insertion of the original logon card will typically be needed for- extending the 
temporary delegation mode session, and. generally, the secure process issues a warning 
message to the user prior to expiration. This is analogous to request for insertion of coins in 
a phone booth during phone calls. Upon expiration, the user interface will be locked and can 
5 be unlocked only by the logon card. If a user attempts to use a time-consuming application 
in a temporary delegation mode, the secure process may request the insertion of a logon 
smart card 19 beforehand to avoid locking the user interface in the middle of an application. 

There are a variety of possible, different temporary delegation modes that generally 
specify the class of auxiliary smart cards 20 and applications allowed during the temporary 
10 delegation mode. For instance, in some modes, perhaps only a single type of auxiliary smart 
card 20 (possibly with traceable ID) is allowed. In other modes, only a small class of 
auxiliary smart cards 20 is allowed. In yet other modes, a large class of auxiliary smart canis 
20 is allowed. 

The exact set of privileges that can be delegated is a function of the system security 
15 policy, a choice by the user (in set-up and/or during the session itself), and the type and 
make of the auxiliar/ card being used. Some privileges may be revoked during a temporary 
delegation mode. For instance, some files (currently on screen or otheoA/ise) may become 
locked once the temporary delegation mode is employed. High security applications might 
request the re-insertion of the original logon card. In an extreme case, all privileges except 
20 for the specific application may be temporarily suspended during the temporary delegation 
mode. 

As an alternative, or in addition, to the embodiments described above, the logon 
smart card 19 may be programmed to categorise different platfomi 10s. For example, 
platform 10s may be categorised as "fairly tmstworthy". -very trustworthy", or "extremely 
25 tmstworthy". depending on the type of the platform 10. In this case, the platform 10 type will 
be revealed by the identity information received by the logon smart card 19 from the platform 
10. The logon smart card 19 is programmed to compare the identity infomiation with pre- 
detennined. stored information, where a particular match indicates the category of the 
platfonn 10. Conveniently, the stored category infomnation forms part of the user profile. 

-^O The seuuiily pul i uy U i at the logon smart card 19 grinpts with a partioHar platform 10 

then depends on the category of the platform 10. in one example, the logon smart card 19 
may transmit different user profile information to the platform 10 depending on the platform 
10's category. For example, with a "fairiy trustworthy" platform 10. the smart card might only 
pass information relating to crypto cards to the platfomi 10. to restrict the user to only being 
35 able to send and receive encrypted emails, or surf , the Internet. Additionally, for "fairly 
trustworthy" platform 10s. the user profile infomnation may limit to 'single-session' temporary 
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delegation modes. In contrast, a "very tnistworthy- platform 10 may receive user profile 
information that pemiits multi-session temporary delegation modes and even cash card 
transactions. Finally, an "extremely taisted" platform 10 would receive user ^^rofile 
information to pemnit all possible actions including multi-session and cash card tran^ 

5 but also other administrative functions. 

An example of an administrative function, requiring an "extremely trusted" platfonn 
10. is the ability to create or modify the user profile of a logon smart card 19. When a logon 
smart card 19 verifies that a platform 10 is an "extremely trusted" platform 10. it passes user 
profile information to the platfonn 10 that includes an option to allow the user to select, from 

10 the secure procfess. a profile modification option. When the user selects the registration 
process, a special smart card registration process Swizard' is displayed. This wizard allows 
the user to add a new auxiliary smart card 20, delete an existing auxiliary smart card 20. and ^ 
view the detailed infonnation of each auxiliary smart card 20's ID. such as its public key or 
certificate. In the user profile, each registered smart card has a distinguished number an^ 

15 name given during its registration. 'Wizards' are well known in the art of computer 
applications, and will not be described in any further detail herein. 

In alternative embodiments, the user profile information may be stored in the trusted 
device 24 or in a remotely located tnjsted platfonn 10. Such arrangements would typically 
require different mechanisms for controlling access by the secure process or platform 10 to 

20 the user profile information, but the use of the information once accessed would remain the 
same. 

While the invention has been described with reference to several pretended 
embodiments, it will be appreciated that various modifications can be made to the parts and 
methods that comprise the invention without departing from the spirit and scope thereof. 

REFERENCES: 

[1] ISO/lEC 9798-3, "Information technology - Security techniques - Entity 
30 authentication mechanisms; Part 3; Entity authentication using a public key algorithm", 
international Organization for Standardization. November 1993. 

[2] ISO/IEC DIS 11770-3 DRAFT. "Information technology - Security techniques - Key 
management - Part 3: Mechanisms using asymmetric techniques". International Organization 
35 for Standardization, March 1997. 
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CLAIMS 

(HP Rcf: 30S800S9) 




1 . Computing apparatus comprising: 

memory means storing the instructions of a secure process and an authentication 

5 process; 

processing means arranged to control the operation of the computing apparatus 
including.by executing the secure process and the authentication process as required; 

user interface means arranged to receive user input and retum to the user 
Infonnation generated by the processing means in response to the user input; and 
1 0 interface means for receiving a removable primary token and communicating with the 

token, the token comprising a body supporting: 

a token interface for communicating with the interface means; 

a token processor; and 

token memory storing token data including information for identifying the token. 
1 5 wherein the processing means is arranged to receive the identity information from the 

primary token, authenticate the token using the authentication process and. if the token is 
successfully authenticated, pemiit a user to interact with the secure process via the user 
interface means. 

and wherein the processing means is arranged to repeatedly authenticate the pnmary 
20 token and cause the computing platform to suspend interaction between the secure process 
and the user if authentication is not possible as a result of the removal of the primary token. 

2 Computing apparatus according to claim 1 . arranged to generate information representing 
the integrity of the computing apparahjs and transmit the integrity information to the pnmary 
25 token, wherein the token processor is programmed to verify the integrity of the computing 
apparatus including by using the integrity information. 

3. computing apparatus according to claim 1 or claim 2. wherein the token data includes 
auxiliary token information identifying one or more authorised auxiliary tokens. 

— '■ — — 

4 computing apparatus according to claim 3. arranged to read the aux-iiary token 
information and. in the event the primary token is replaced by a different token, detect 
whether the different token is an authorised auxiliary token. 

35 5 Computing apparatus according to claim 4. arranged, if the different token is an 
authorised token, to allow the secure process to interact with tiie authorised token. 
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6. Computing apparatus according to claim 5, wherein the authorised token is a cash token 
and the secure process is arranged to credit or debit the token. 



• 

>to roken 



5 7. Computing apparatus according to claim 5. wherein the authorised token is a crypto ^ken 
programmed to encrypt, decrypt or sign data, and the secure process is arranged to transmit 
data to the crypto token to be encrypted, decrypted or signed and receive encrypted, 
decrypted or signed data from the crypto token. 

10 8. Computing apparatus according to any one of claims 4 to 7, arranged, only if the different 
token is an authorised auxiliary token, to allow the user to interact with the secure process. 

9. Computing apparatus according to any one of claims 4 to 8. further comprising timer 
means programmed with a timeout period, wherein, in the event the different token is an 
15 authorised auxiliary token, the computing apparatus resets the timer and continues operation 
until the timeout period expires, after which time the computing apparatus suspends any 
interactions between the secure process and either or both the user and the authorised 
auxiliary token. 

20 10. Computing apparatus according to claim 9, arranged to recommence said interactions in 
the event the authorised auxiliary token is replaced by the primary token and the computing 
apparatus is able to authenticate the primary token. 

11. Computing apparatus according to any one of claims 4 to 10, arranged to permi 
25 interaction between the secure process and .only one authorised auxiliary token after removal 

of the primary token. 

12. Computing apparatus according to any one of claims 4 to 10. arranged to permit 
interaction between the secure process and more than one authorised auxiliary token after 

—30 — removal of the primary tpken 

13. Computing apparatus according to any one of the preceding claims, wherein the 
processing means comprises a main processing unit and a secure processing unit and the 
memory means comprises main memory and secure memory. 

35 
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14. Computing apparatus according to claim 13. comprising a trusted device incorporating 
the secure processing unit and the secure memory, wherein the trusted device is 
programmed to authenticate the primary token repeatedly. 

5 15. Computing apparatus according to claim 14. wherein the trusted device is arranged to 
acquire an integrity metric of the computing apparatus, and the primary token is arranged to 
use the integrity metric on at least one occasion to verify the integrity of the computing 
apparatus. 

10 16. Computing apparatus according to any one of the preceding claims, wherein the primary 
token comprises a smart card, and the interface means is configured to receive a smart card. 

17. Computing apparatus according to any one of claims 3 to 16. wherein the auxiliary token 
information is stored In a user profile. 



15 



18. A method of controlling computing apparatus to authenticate a user, comprising the 
steps: 

the computing apparatus receiving a primary token of the user, the primary token 
containing information suitable for authenticating the primary token; 
20 if the token is authentic, permitting the user to interact with one or more secure 

applications that may be executed by the computing platfonn; 
at intervals, re-authenticating the primary token; and 

if it is not possible to re-authenticate the primary toker^. suspending the interaction 
between the computing apparatus and the user. 



25 



19. A method according to claim 18. further comprising the steps: 

the computing apparatus providing Integrity metric information to the primary token; 
the primary token using the integrity metric information to verify the integrity of the 

computing apparatus: and 

-^0 if Lite pr imary token io unab l o to v e rify the integrity nf the computinq apparatus. 

suspending interaction between the computing apparatus and the user. 

20. A method according to claim 18 or claim 19. in which the primary token includes 
information relating to one or more authorised auxiliary tokens, wherein, if the user replaces 

35 the primary token with an authorised auxiliary token, the computing apparatus permits 
interaction between the auxiliary token and the computing apparatus. 
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21. A method according to claim 20, wherein the computing apparatus interaction with the 
authorised auxiliary token for a limited period of time. 




5 22. A method according to daim 20 or claim 21. wherein the computing apparatus only 
permits interaction with one authorised auxiliary token after removal of the primary token: 

23. A method according to claim 20 of claim 21 , wherein the computing apparatus permits 
interaction with plural authorised auxiliary tokens after removal of the primary token. 

10 

24. A smart card programmed for operation in accordance with any one of claims 18 to 23. ^ 

25. Computing apparatus configured for operation in accordance with any one of claims 18 
to 23. 

15 
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